next up previous
Next: 5.1 Example of Execution Up: X Server Multi-rendering for Previous: 4.3 Virtualized Direct Access

5 Multi-rendering Implementation

When the X server first starts, no multi-rendering threads exist. Neither the PEX nor the OpenGL extension have been initialized. The main X server process creates a rendering thread for a client when the client first uses either the OpenGL or PEX extensions. Once created, the rendering thread exists for the lifetime of the client. A per-thread structure associated with the client holds the semaphores, data, and pointers that the main thread and the rendering thread need to communicate with each other. There is at most one rendering thread per client.

Each newly created rendering thread performs some basic initialization, then waits on a blocking user-level semaphore until the main thread commands it to perform some item of work. When the main thread decodes a protocol request that requires access to rendering hardware, it creates a command structure and fills it with information about the protocol request to be executed. The main thread then ``hands off'' the command structure to the rendering thread by releasing the semaphore that the rendering thread was waiting on. The main thread continues servicing client connections and device input. Request dequeueing and dispatch for the multi-rendering client are suspended until the main thread is informed that the rendering thread has completed its task.

The mechanism that reports completion back to the main thread must be non-blocking. The main thread must be free to service other clients while multi-rendering is in progress. So when the rendering thread has completed, it alerts the main thread via a pollable semaphore. If the main thread is blocked in select when the completion occurs, it is awakened immediately, and resumes request processing for the multi-rendering client. If instead it is busy processing a request for some other client when the completion occurs, the main thread will be informed of the multi-rendering completion the next time it calls select.

When a request is handed off to the client's rendering thread, the main server thread ``pushes back'' the current request on the client's input connection while waiting for completion. This allows completion status to be reported synchronously back to the client.

Because any PEX request can fail and report an error condition, a push-back mechanism is always used for PEX rendering requests. A push-back means that when the client processing is resumed, it is still at the same request. In contrast, most OpenGL rendering does not define protocol replies or errors so the OpenGL extension can avoid push-back for most OpenGL commands.

Pre-existing capabilities in the X server are used to implement the scheme described above [13]. The IgnoreClient function is used to suspend processing on the client until the multi-rendering task is completed; AttendClient then allows that processing to continue. Block and wakeup handlers are used to modify the X server's select mask to add the file descriptors for the pollable semaphores used to signal multi-renderer command completion. The ResetCurrentRequest server function performs the push-back operation.





next up previous
Next: 5.1 Example of Execution Up: X Server Multi-rendering for Previous: 4.3 Virtualized Direct Access



Mark Kilgard
Sun Jan 7 19:20:04 PST 1996